feat(upload): --idempotency-key and --dedupe - #21

What

Exposes the API's retry-safety and content-reuse options (pixelvault#335) on pixelvault upload:

• --idempotency-key <key> → Idempotency-Key header. Repeating the same key with the same file returns the original image (API: 200, replayed: true). Single file only: one key can't cover several different files.
• --dedupe → dedupe=true. The API reuses an identical image already in the project and doesn't count another upload.

Both are validated before any file is read; --dedupe + --idempotency-key is rejected (mirrors the API's 400). A "Replayed" / "Deduplicated" note goes to stderr, so stdout remains the bare URL and existing scripts are unaffected.

Not in this PR

Version bump / release. I'd cut it as 0.9.0 in a separate chore: release commit + v0.9.0 tag, as with 0.8.0. The skill doc should merge only after that publish.

Test plan

• tsc --noEmit, 78 tests (new: validateReuseOptions for key shape, combo, multi-file)
• Ran the real CLI process against a local fake API: header and form field are actually sent; stdout is just the URL; the replay and dedup notes land on stderr; the invalid combos exit 1 with a message and send nothing
• Against the real API after pixelvault#335 (already deployed): pixelvault upload a.png --idempotency-key smoke-1 twice should print the same URL, with "Replayed" the second time

🤖 Generated with Claude Code